1. Field of the Invention
This invention relates to transaction processing systems, and more particularly, to autonomic control and administration of individual transactions or groups of transactions based upon their unique current resource usage characteristics relative to the present status of one or more present characteristics of the transaction processing system or the host computer system.
2. Background Description
Transaction processing systems serve as a basis for electronic commerce. In electronic commerce two or more entities electronically process specific tasks related to commerce ranging from purchase and payment to banking transactions. Examples of electronic commerce include purchase and payment transactions using credit and debit cards, paying bills online and the handling of return merchandise credits. Transaction processing systems also facilitate the accessing of data across a network, such as the Internet. Browsing merchandise on a vendor's website, obtaining stock quotes from a financial service institution's website and checking sporting event scores at a news website are examples of such accesses. Other examples of routine network transaction events include the interchange of data that occurs during online gaming, downloading product updates from a software vendor's server and the exchange of email.
Prior to the days of the Internet, an example of a transaction processing system would be a given corporation's internal users accessing a host mainframe processor, with individual transactions being serviced via an executing software “transaction monitor”, such as, for example, IBM's CICS (Customer Information Control System). With the advent of the Internet, an example of a transaction processing system includes the server or servers that host a given Internet website, along with the underlying hardware and software infrastructure, frequently including an “application server” such as IBM's WebSphere Application Server.
Transactions that are serviced by a transaction processing system may come from any number of sources, examples of which include users accessing the system from a home or office personal computer, personal digital assistant (PDA), network-enabled cellular devices and automated teller machines (ATM's). Additionally, transaction processing systems may also be accessed by other systems, such as partner transaction processing systems, interactive voice response systems, or any other automated entity that has access to the transaction processing system through a network.
For a variety of reasons such as application errors, hardware faults and unintended use of the transaction processing system, there is a chance that a transaction or group of transactions may take on characteristics that are outside of the design specifications of the transaction processing system. Actions commonly taken to eliminate the undesirable workload from the system could range from purging the transaction to shutting down and restarting the entire transaction processing environment.
In other cases it may simply become desirable to favor one type of work versus another type based upon current general system conditions, such as high utilization or the like. Current practice facilitates the remediation of these conditions through binary evaluation. For example, if a given transaction on a transaction processing system has consumed more than a predetermined number of CPU seconds, then the offending transaction is terminated. A termination of an offending transaction may also occur, for example, if a given transaction were consuming more than some predetermined amount of electronic storage.
Current practice also allows for indiscriminate termination of transactions in the event of an alert on the transaction processing system. An example of the type of condition that would trigger such an alert is when a short on storage event occurs within the transaction processing system.
A shortcoming of the current practices arise from the indiscriminate nature of transaction administration. In practice, transaction processing systems purge transactions that exceed some arbitrary limit, without regard to whether the limit that was exceeded is presently constrained on the transaction processing system.
A further shortcoming is when remedial action is taken or initiated to address an alert from the transaction processing system, but the nature of the action is poorly targeted and/or overly drastic, affecting transactions that have little or no bearing on the alert, itself. Currently in transaction control facilities, autonomic corrective action is typically ill-targeted, poorly timed, and affects the user community too broadly.